PsL Monthly 1993 December

home *** CD-ROM | disk | FTP | other *** search

/ PsL Monthly 1993 December / PSL Monthly Shareware CD-ROM (December 1993).iso / prgmming / dos / tools / mdem4b.exe / MANUAL.TXT < prev next >

Wrap

Text File | 1992-06-12 | 60.5 KB | 1,456 lines

M A K E D E M O ----------------- Version 4 ----------- U S E R ' S M A N U A L --------------------------- Last updated: June, 1992 _______________________________________________________________ | | | MakeDemo is NOT a public domain program. It is Copyright (c) | | 1989 - 1992 by WindhamWoods Publishing. All rights reserved. | |_______________________________________________________________| COPYRIGHT INFORMATION This software and accompanying documentation are protected by United States Copyright law and also by International Treaty provisions. Any use of this software in violation of Copyright law or the terms of LICENCE.DOC will be prosecuted to the best of our ability. The conditions under which you may copy this software and documentation is clearly outlined in LICENCE.DOC. Registered users may install MakeDemo on a computer attached to a network, or remove it from one computer and install it on another, provided that the copy will not be used by more users than the number for which it was licensed. As a registered user, you may distribute any file which you create in part or in whole with this software. Further, you may include any screen(s) that you received with the MakeDemo distribution as part of your own presentation(s). Licensee shall not use, copy, rent, lease, sell, modify, decompile, disassemble, otherwise reverse engineer, or transfer the licensed program except as provided in this agreement. Any such unauthorized use shall result in immediate and automatic termination of this license. Where differences exist between the foregoing information and that contained in "LICENCE.DOC," the latter shall govern. ASP Information _______ ____|__ | (R) --| | |------------------- | ____|__ | Association of | | |_| Shareware |__| o | Professionals -----| | |--------------------- |___|___| MEMBER "This program is produced by a member of the Association of Shareware Professionals (ASP). ASP wants to make sure that the shareware principle works for you. If you are unable to resolve a shareware-related problem with an ASP member by contacting the member directly, ASP may be able to help. The ASP Ombudsman can help you resolve a dispute or problem with an ASP member, but does not provide technical support for members' products. Please write to the ASP Ombudsman at 545 Grover Road, Muskegon, MI 49442 or send a CompuServe message via CompuServe Mail to ASP Ombudsman 70007,3536." Table of Contents a. Copyright Information I. Introduction II. The Files of MakeDemo III. Installation IV. Starting Up MakeDemo V. What MSHOW looks for in your Creation Menus Predefined System Menu Selections Code Those Screens Menu Mechanics Prompt Screen Be Mouse Ready VI. Creating a Presentation with MDEMO MDEMO Features Using a Mouse Large Fonts Overlays, the Key to Presentation Effects Viewing a Work-In-Process VII. Making Single .EXE File Presentations Branding (Optional) VIII. MLITE, The MakeDemo Stripped Down Runtime IX. MDEMO Quick Reference X. Customer Support _______________ I. Introduction MDEMO, for creating, and its companion MSHOW, for viewing a presentation, together comprise the MakeDemo system that gives you the ability to present information on a PC or compatible computer of almost any persuasion, color or monochrome. And then there is MLITE, a stripped down version of MSHOW with some limitaions on features but worth the trade-off where disk space is a premium. See section VIII for the differences. MakeDemo's architecture promotes o presenting information in as many as 2000 screens that include your own menus and sub-menus, as you define them. o small files: a typical 100 screen self-contained presentation consumes 120 kBytes: great for downloading over BBSs. o small memory usage: less than 80 kBytes of RAM, less memory intensive than many TSR applications. o your own user interface design: you design all screens including prompt screens, context sensitive help, etc. o language independence: your client sees only what you create. There are no hard coded screens or messages that pop up in your presentations. o capability of shelling out to DOS to run other program(s). First, there's MSHOW.EXE. By itself it does nothing: rather it reads an external or appended 'resource file'. Think of MSHOW as a library of functions that can interpret your 'presentation' or resource file that you create with MDEMO. Second, there's MDEMO.EXE, used to create presentations to be displayed by MSHOW.EXE, either separately or combined with a presentation to form a single EXE file. MakeDemo gives the novice through expert user the ability to create slide show type presentations with sound effects, various screen overlaying techniques, and various delays with interactive menuing and mouse support. MakeDemo includes tools to put full presentation into a single .EXE file complete with "F1 - Help" and your own order form: no extra file listing each screen for a presentation or a script language to learn if you want to include menus. MakeDemo is to screens what a good word processor is to paragraphs. Think of MakeDemo as a text organizer for files of screens, not paragraphs. As you work on a creation, add screens, insert blank screens, import text in 25 line chunks from ASCII files, screens captured from other software, or other MakeDemo files, in part or in whole. Then edit one screen at a time, move segments around or copy segments to "place" on other screens. Make copies of screens. Delete screens. Save groups of screens to new files. Sounds like a word processor: except that you scroll through a file screen by screen rather than line by line. All with mouse support. But MakeDemo is more. Give your users control in how to view presentations. Simulate menu driven software for very realistic demos. Create a hypertext sort of system for quickly moving through a large presentation, such as a catalog or book on disk. Manually override color/monochrome display formatting. Now, when a "color display" is not stricly a color display, switch over instantly without first exiting to DOS, typing in some modifying commands, and then restarting the presentation all over again. In fact, view a presentation in process being created in color, as it would appear on a monochrome display. Choose from many large fonts when creating outstanding screens. Create boxes with automatic correction for crossing lines. Customize your own or add to selection of boxes and fonts with almost any ASCII text editor. PLEASE NOTE - Only one version of MakeDemo exists for both shareware and registered use. Without the correct validation code, MDEMO comes up in the 'shareware' mode. You need to register your use of MakeDemo in order to receive your assigned validation code in order to bypass the 'shareware' mode. Both MDEMO and MSHOW have identical and integral WindhamWoods Publishing 'nag' screens that appear when certain conditions are detected. Similarly, MLITE produces a single line "reminder." Shareware Users: The 'nag' screens appear if - 1. You run MDEMO from the command line and do not include the correct validation code. 2. You start MSHOW or MLITE to view a presentation either with no file specified at all, or with a presentation file specified on the command line (or integrated into a single .EXE file) created, or last edited, with an unregistered version of MDEMO. In all cases, whenever the 'nag' screen appears, pressing any key erases that screen and lets you continue, unheeded. Registered Users: The serial number for your copy of MakeDemo is located on the 2nd line of the file MDEMO.WWP. Upon start-up, MDEMO reads that number and imbeds it and the validation code that was included on the command line with MDEMO into any presentation file that is edited or created. As a registered user, make sure that the serial number is yours. The validation code will only work with it to circumvent any WindhamWoods 'nag' screens from appearing. _________________________ II. The Files of MakeDemo MakeDemo is supplied in three self-extracting files listed below. Not only does packing MakeDemo into three files take about half the disk space, installing MakeDemo on your system is also easier. Packed into each is the same PACKING.LST file that completely lists all of the individual MakeDemo files. The following is a brief description of the three files. While each can stand alone in its own right, all three contain files necessary to successfully produce a MakeDemo presentation. For detailed information on installing MakeDemo on your system, please read section III - Installation. MDEM4A.ZIP Overview of MakeDemo .EXE Contains the necessary files to produce a single .EXE executible file, DEMO.EXE from WATCH_ME.1ST created with MakeDemo. The resulting file with about 55 screens is a fully functioning sales pitch for MakeDemo. MDEM3B.ZIP A More Elaborate Presentation .EXE This time you can create a single file presentation of MakeDemo's "help" facilty. With about 200 screens, this presentation also created with MakeDemo is a more elaborate example of MakeDemo's capabilities. And this archive also contains the MakeDemo manual. MDEM4B.ZIP MakeDemo Files .EXE Contains MDEMO.EXE and the ancillary utilities such as the screen capture utility for those who are ready to start creating their own presentations. Also included are the various .DOC files that complete the MakeDemo package. And for those who would like a bare-bones MakeDemo runtime, there's MLITE.EXE, great for a "shareware" front end to your own programs. _________________ III. Installation MakeDemo was designed to be accessed from its own directory. Therefore, you should place all the files supplied with MakeDemo in its own directory and include that directory in the PATH statement of your AUTOEXEC.BAT file. IMPORTANT NOTE: Be sure to reboot your computer after modifying your AUTOEXEC.BAT file. If you need help in this area, consult someone knowledgable in the workings of DOS. MakeDemo as supplied in three self-extracting files is ready for "unpacking" and placing on your hard disk (preferable) or other floppy disk. The full complement of files takes about 500 kBytes of disk space plus 250 k Bytes for the example files you'll be creating as you get started. As part of the unpacking process, you can declare a destination directory that doesn't as yet exist, in which case it will first be created automatically and the files unpacked to it. In that case where the directory exists and the files of an older version of MakeDemo reside in it, you will be asked whether to overwrite an existing file of the same name, to which you should answer "yes." HARD DISK INSTALLATION Simply place the disk in the A drive and type MDEM4A C:\MDEMO and press <Enter>. in like manner type MDEM4B C:\MDEMO and <Enter>. in like manner type MDEM4C C:\MDEMO and <Enter>. Once you have included the MakeDemo files in its own directory and have included that directory in the "PATH," you can then call up MakeDemo from within any other directory. There's no need to keep multiple copies of a file and then inadvertantly loose track of the current one. FLOPPY DISK INSTALLATION Use of MakeDemo on a computer without a hard disk is not recommended. The following information is provided for those hearty souls who persist in overcoming self imposed limitations. You need to format four disks before continuing. Simply place the master disk in the A drive, one of the formatted disks in drive B, and type MDEM4A B: and press <Enter>. When completed, label disk "MSHOW." in like manner type, place another formated disk in drive B and type MDEM4B B: and <Enter>. When completed, label disk "HELP." in like manner type, place another formated disk in drive B and type MDEM4B C: and <Enter>. When completed, label disk "DOCS." The fourth disk holds the files for creating and viewing a presentation. Place the fourth disk in drive A and the "DOCS" disk in drive B and type COPY B:MDEMO.EXE A: COPY B:*.WWP A: Replace the disk in drive B with the "HELP" disk and type COPY B:MDEMO.HLP A: Replace the disk in drive B with the "MSHOW" disk and type COPY B:MSHOW.EXE A: When completed, label disk "MDEMO." ________________________ IV. Starting up MakeDemo Let's start by making an executible of the MakeDemo "help" system, just as you might do yourself. All the DOS machine instructions are contained in the DEMO.BAT file, all ready to run. The MDEMO.HLP file and MSHOW.EXE are combined to form M_HELP.EXE. The first time you run this program, you'll see the 1st screen of the "Help" file, a menu screen, AND you will see disk activity while your computer crunches away creating an index of all the screens in the "Help" file. The time it takes to complete this chore depends upon the type machine you are using. You can use the presentation while the indexing continues in the background, but response will be sluggish. It's best to wait until the process is completed before trying to maneuver through the file. Once the index is created, subsequent viewings will start almost immediately: the index, stored to disk is not recreated, but is automatically read from disk into memory, a much faster operation. As a registered user, you received a validation code. If you wish to use MakeDemo and bypass the "Shareware" screens, you must include your validation code on the command line when calling up MakeDemo. NOTE: If you have installed MakeDemo on your hard disk in its own directory, and have included its directory in the "PATH" statement of your AUTOEXEC.BAT file and then rebooted, you're all set to change direcory to any other and call up MakeDemo. If, on the other hand, you are using a dual floppy system, place your MDEMO disk, the fourth one you created in the unpacking process, in drive A and a preformatted disk in drive B. At the DOS prompt type PATH=A:\. Then log onto drive B and you're ready to call up MakeDemo. For example, if your validation code is SK1234, you would type MDEMO SK1234 and <Enter>. Remember, that code is uniquely yours. Giving it to someone else along with the program really isn't much of a gift. After all, the shareware 'nag' screens aren't really that obnoxious. But violating the copyright laws deprives the authors of MakeDemo from receiving fair value for value rendered. If you have any questions once you have called up MakeDemo you can press F1 to see the "Help" categories from which to select more detailed help. There's a lot of information in this help file. It is in itself a MakeDemo creation, similar to something which you yourself might wish to create. To learn as much as possible in as little time as possible as to what makes a great presentation, use MDEMO itself to "Edit" the help file. There's no need to make any changes to the file. Just go through the screens and see how the menus are defined and what "appearance" options have been selected. To "Edit" the help file, select for the working directory that which contains the MakeDemo files, normally the MDEMO directory. At the DOS prompt type MDEMO and the validation code, if you are a registered user, and press <Enter>. When the menu appears across the bottom of the page, select "Files," highlight the help file, "MDEMO.HLP," and press <Enter>. Up will pop the first screen of the file. Now to see more of the screens, use the down and up arrows to move through the file, observing how the menus are constructed. For now, just observe. The details follow a little later in this document. Select "More" to get the other half of the main menu and select "Appearance" to see what methods were selected for the screen that is shown. When you're finished, press <Escape> and follow the directions. _________________________________________________________________ V. What Gives MSHOW a Clue as to What, Where, and How to Present You need not be a 'programmer' in the old sense of the word in order to create a masterpiece. Knowing one's way around a word processor is qualification enough. To create an MSHOW 'presentation' requires following a few simple rules, which we will get to shortly. MSHOW interprets your presentation or resource file. There are just a few rules that impact how you go about its design. Your presentation or resource file is nothing more than a series of screens that describe to MSHOW your application. All the unique information is placed on the screens themselves. Upon presentation, this 'coding' information is blanked out. Upon startup, MSHOW almost immediately puts up the first screen, but then continues to 'index' the remaining screens in the background until completed. Indexing performs a number of functions. MSHOW creates a list, by name, of all screens in memory. MSHOW lets you include 'menus' in your document that uses this index of screen names. A menu is a list of choices, or screens, from which your user can select to view next. Hence, only screens that must be referenced need a unique name. MSHOW saves this index to disk in a file of the same name, but with the ".INX" extension. When preparing to display a presentation MSHOW first looks to see if the index filke exists on disk. If it is found and its date/time stamp is more recent than that of the presentation file itself, MSHOW reads it into memory. Once created, this feature is a real time saver, especially on slower systems. The index file is in reality an ASCII text file. It can be printed out using the DOS TYPE command. The name and length of each screen is stored seuentially, each separated by commas. You might want to refer to this file created by your own presentation in order to eliminate conflicts in screen names. You may also "code" your creation to become a self-running presentation of sorts. If you wish to let your users view your document as a presentation (ie. automatically present screens in menu order at pre-programmed intervals) and automatically recycle indefinately, or <Esc> is pressed, give your viewer access to the presentation options. (see the system menu options) Menus: There is an optional menu screen and then there are the menus that are part of information you are presenting. The system menu, or virtual menu, has the rudimentary selections such as <F1>, <Esc>, <PgUp>, <PgDn>, and <Tab> always active, regardless of whether or not you assign additional keys to them or not. More about that later. These selections are always active whether or not they can be seen on the screen. These menus, if you have defined your own, are always as close as the <Tab> key or by moving the mouse to one of the screen edges. There are reserved names for these screens which MSHOW looks for upon startup. MSHOW looks for one and only one screen with one of these names LSIDE0 TSIDE0 BSIDE0 RSIDE0 PLEASE NOTE: These names are reserved and are not to be used for any other purpose. If you do by chance try to include them in your own menu, strange things will happen and the results will be something less than acceptable. The architecture of MSHOW allows, even encourages, you to design these system screens to your own taste. Of course, feel free to use whatever screens you like of those supplied with MakeDemo. If you like, modify them with your your own context sensitive "Help". There are a number of predefined functions which your system menu may or may not include. That's up to you. For example, to give your viewer the ability to shell out to DOS, you must include the appropriate instructions on the system menu screen. Certain names are 'reserved' and if used, MSHOW expects conformance to the appropriate schema. We'll get into this schema later, but in the interests of being concise, all the information you will need for referal purposes is included here in one place. Those menu selections are Hard- Soft- Coded Coded Actions Performed Keys Functions ----------------------------------------------------------------- <Esc> QUIT returns the user to the previous menu, or out to DOS, whichever comes first. In the AUTO presentation mode, discussed below, the first press of <Esc> puts MSHOW into the SOUND mode, discussed below. <PgDn> PAGEDN causes the next screen to appear provided screen has no name. A name of "+" or "-" is permitted where a repeating presentation is desired. <PgUp> PAGEUP causes the previous screen to appear provided the present screen has no name. A name of "+" or "-" is permitted where a repeating presentation is desired. <Tab> TAB causes MSHOW to search all screens stopping at the first with the name "_SIDE0". The "_" represents the characters "R", "T", "B", or "L". When using a mouse, MSHOW can differentiate between the various options, but without the mouse, MSHOW has no clue as to what the first letter might be. Only one system menu screens is permitted. <F1> HLLP You can provide a sequence of screens as a general "Help" facility. These might be of a more general nature, explaining the typical maneuvers to progress through a presentation. When a system menu screen is being presented, either by pressing the <Tab> key or moving the mouse to an edge, MSHOW presents the first overlay it finds on the screen. (Hopefully it is the system menu.) All other screen segments on that screen only appear when F1 is pressed. (See section on screen overlays. POFRM Use this name to define a sequence of screens, such as a Purchase Order Form, that can be accessed from the system menu and or associated "hot" key. Of course, you can name your order form something different and give access to it from your own menu. PRIN This keyword tells MSHOW to retrace to beginning of a menu selection or order form and send all the pertenent screens to the printer. You have the option of including a "prompt" screen, discussed further on, to give the user the opportunity of aborting the process before actually starting the print operation. If the "prompt" screen does not exist in your file, MSHOW sends the form to the printer, by default. A screen is a chunk of 25 lines each. If you want to print a form on a single sheet of paper of 60 lines, you are not limited to 2 screens. To prevent particular lines from going to the printer, merely place an <Alt>13 symbol at the beginning of that line on the screen. MSHOW ignores it and skips to the next line. SHELL Give your users the ability to interupt viewing a presentation so as to temporarily go to DOS for doing something else, and then return to the application without losing a step. COLOR MSHOW detects whether the system is configured with a monochrome or color monitor. In those cases where the user might not be happy with the default, include this ability to switch. FFUNC reserved, but not used. RSVD reserved, but not used. R e s e r v e d f o r P r o m p t S c r e e n O n l y ------------------------------------------------------------- YES NO P r e s e n t a t i o n O p t i o n s --------------------------------------- N_EFFECT No sound or graphics effects EFFECT Graphics Effects such as overlay sliding, etc. SOUND Same as above, but includes preset sound effects AUTO Self running presentation with programmed delays As part of your presentation, you have the ability to include your own menus that allow the user to move through a file in response to your defined menu selections. One group of screens might explain certain features of your system, another might be your order form. You can design menus with up to 30 selections on a single screen, sub-menus up to fifty deep, with a total of 2000 screens in one file. Think of it as sort of a hypertext application. How do we Code the Screens for MSHOW to Interpret ? There is very little specific coding information that MSHOW needs to access. MSHOW is designed to do quite a lot on very little information. MSHOW does need to be able to discover the names you give to the first screen of a screen sequence. All these pieces of information are imbedded in lines starting eith either , or ( ie. <Alt> 4 or <Alt> 6 respectively.) These characters are keyboard accessible by simultaneously pressing the <Alt> key and the appropriate number key on the numberic keypad. Lines prefixed with either of these symbols can up to 80 characters long and must appear within the top 6 lines of a screen. If one line is insufficient, use additional lines, provided each starts with the appropriate symbol followed by a comma. The name following either of the first two symbols can only appear once, if at all, on a screen. Generally speaking, the characters following these symbols mean - ( <Alt+4> ) screen name and menu selections ( if any. ) ( <Alt+6> ) designates the place on the screen where, just to the right, the menu selection. The area of the screen can have multiple lines but can not exceed 256 character spaces. (For example, 8 rows by 32 columns.) MSHOW uses the color attribute of the area to delineates it from that of the surrounding area. Let's take a closer look at the attribute. This is an important point. MSHOW defines the width of a field by looking for a background color change as it moves from left to right after finding the beginning of the selection or field. The foreground color (the printed characters) can differ along the line but not the background color. when a change is determined, meaning that the width has been calculated, MSHOW then travels down the screen in this last column looking for identical foreground and background colors. If found, MSHOW assumes that the selection or field is more than a single row and continues down the column looking for a change, hence the last row. This is important. Menu selections or fields can be placed on consecutive rows using the same background / foreground colors. You ask "How can that be?" By using a different foreground color for the last character location on a line (usually this can be a space and the foreground color doesn't show) adjacent rows that end in the same column will not interfere with each other. The Mechanics of a Menu: Here is a typical menu designation. It names the screen "MENU" and contains six menu selection. Note each line is prefixed with <Alt+4>. Some printers are unable to print this character directly. MENU,ITEM1,ITEM2,ITEM3,ITEM4 ,ITEM5,ITEM6 MENU - is the name of the screen. ITEM1 - is the first menu selection. ITEM2 - is the second menu selection. ...and so on. A screen should never be given a name unless it its to be assessed from another menu. Here's the rational. MSHOW allows the user to <PageDown> to adjacent screens if and only if that screen has no name or if that name is prefixed with a "+" or "-". If you wish to let your users view your document as a presentation (ie. automatically present screens in menu order) and automatically recycle indefinately, or until <Esc> is pressed, name the last screen, "-", and the screen to return to name "+". For example, if you want a repeating presentation to restart with screen 4, name screen 4 "+". And of course, name the last screen of the last menu selection "-". When <PagingUp> MSHOW lets you go no further back than a screen with a name. It shouldn't be too hard to visualize that a sequence of screens can be made inaccessible simply by giving the first of the sequence a name and then NOT including that name in any of your menus. The screen name, in this case "MENU", indicates that this screen, in addition to having a menu of its own, is to be accessed only from another menu screen. MSHOW recognises hot keys and/or function keys that you so designate as part of your menu. To use this feature you include the designator with the menu selection above. For example, if we change menu item 1 to "ITEM1=B-FF6", then pressing the 'B' key or the 'F6' function key will also cause item 1 to be selected. A more realistic selection might be "SHELL=S-FF6". If you layout the menu screen with the "S" for "SHELL" bright white and the rest of the letters the subdued while or grey, right away the user intuitively knows that pressing the "S" key will cause "SHELL" to activate. All the keys of the alphabet are permited as well as all the Function Keys, Control / Function keys, Shift / Function Keys, and Alternate / Function keys. The following is a list of the possibilities. FF1 through FF10 CF1 through CF10 SF1 through SF10 AF1 through AF10 You can designate a hot key with a different foreground color for that key in your actual menu selection. IMPORTANT NOTE: The equal "=" sign must preceed the "hot" key, the "-" must preceed the function key designation. Failure to respect this constraint will appear as non working or unwanted key assignemnts. For example, the following example should clarify things. Here is a menu selection of 4 rows of 20 characters each. The 'x' designates different foreground / background colors from those of the surrounding area. <Alt+6> xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx You can place selections anywhere on the screen, put them in list boxes or in bars like those of MakeDemo. Or you can imbed them in text to make certain words "hot." Think of menus as a tree with branches. Start at the base of the tree (DOS) and climb up into the tree and trace your steps as you explore out to a leaf. You probably won't give your viewers as many choices as they explore your "tree," but the concept is similar. With MakeDemo the branches can vary in length, which is to say that you can show a number of screens before coming to the next named screen for another menu selection defined elsewhere. MSHOW lets your viewer progress through a series of screens until the next screen has a name defined. Trying to progress further returns the viewer to menu from whense he or she came. Except... There might be times when you might allow the viewer to move into the next menu selected series of screens without first returning to a menu. For example, if you are putting together a catalog with a "Table of Contents," you might just as well let the viewer roam around in the general area without forcing a return to the "menu," before moving on. However, MakeDemo does impose a few restraints on such activity. The viewer can traverse backwards through the presentation only until he or she comes to a screen with a label on it. You remember: a "label" is used by the menu to know which screen to present when a menu selection is made. For example, suppose screens are arranged as follows: Screen Label Choices 1 2 <ALT+4>+MENU,,GOTO1,GOTO2 <ALT+6>GOTO1 <ALT+6>GOTO2 3 <ALT+4>HLLP 4 5 6 <ALT+4>GOTO1 7 8 9 <ALT+4>GOTO2 10 11 12 13 14 <ALT+4>-MENU This would be a typical organization for single .EXE presentation file. Here there would be a menu somewhere on screen 2 with two choices: "GOTO1" and "GOTO2." Screens 6, 7 and 8 associated with GOTO1 and screens 9 through 14 are reached by selecting GOTO2. There is only one way to get to screen 6: that is by selecting GOTO1 from screen 2. However, there is an additional way to access screen 9; that is from screen 8, but only f the screen name were prefixed by a "-" sign. Now, if all that is true, then how does one access screens 3 through 5? That's simple; just press F1. Those screens are the "Help" facility, if you choose to have one. To include "Help," the first screen must be labeled "<ALT+4>HLLP". The "Help" screens should always be placed just after a menu screen or after the last screen of a choice. In that way there is no way for the user to stumble into Help except by pressing F1. Now, you may inquire about the choice on screen 14. There are several things you can do on the last screen. We chose to use the name of screen 2, the reason being that trying to move beyond that screen either in manual or automode will cause the presentation to repeat the presentation starting with screen 2. Or I could have given it no name, in which case, the presentation would wait there indefinately for someone to press <Esc>, which would precipitate a return to DOS. Three is one other nuance having to do with menus that you might have missed in viewing the presentation. For the sequence of screens shown above, you might have wondered what would happen when MakeDemo presented a menu while in the "auto" mode. Well, MSHOW would assume that you want to sequentially go through the menu and present every branch out to each leaf, return to the menu and follow the next branch, and so on. There might be a situation where you would like your viewer to be in automatic mode, but then stop at a menu screen and wait indefinately for a key press. To do that merely preceed the name of the menu screen with a question mark, "?". MakeDemo leaves it up to you as to how you wish your viewers to use your presentation. "PROMPT" Screen There are a number of situations whereby you might wish to prompt your user with a question and wait for an answer before proceeding. For example, before sending something to a printer, you might give your user instructions and a chance to abort the process before continuing. The screen name "PROMPT" is reserved for such an event. The screen is defined with <Alt+4> PROMPT,,,, and the screen is layed out with 5 selections, the first three designated for information display, the last two for possible answers. For example <Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <Alt+6> Yes <Alt+6> No The same rules apply here as for menu selection. And then somewhere on this screen is the information to be used when a prompt message is to be displayed. For example, 9,Order Form is Next,Prepare Printer,Continue ?,YES=Y,NO=N,1 The first character, in this case, the '9' is sacrosanct as well as the 'YES' and the 'NO'. The labels on the screen can be anything, but here they must be as shown. The three character strings appearing after the '9' can be anything you like to be displayed centered on the three lines. The individual strings can be any length, but total length of the line can not exceed 80 characters and must start at the left edge of the screen. And last but not least, the last character, her a "1" is the default if neither of the selections is selected: a "1" indicates a YES, a "0" indicates a NO. Be Mouse Ready: Certain screen areas are "hot," namely the edges: top, bottom, left, and right. pushing the mouse to an edge causes MSHOW to look for a system menu screen named "TSIDE0", "BSIDE0", "LSIDE0", "RSIDE0", representing top, bottom, left and right edges respectively. If one of these screens exist, the menu is presented. Usually such a screen is constructed of two segments: the menu and its context sensitive help. To work properly, the menu must be positioned such that MSHOW finds it first before finding the "help" segment. Remember, MSHOW searches a screen left to right, top to bottom, to find a segment to display. With this scheme it is not possible to place a menu across the bottom of the screen with the "Help" segment above it. The menu must be found first. _____________________________________ VI. Create a Presentation with MDEMO MDEMO is to screens what a word processor is to pages. Upon typing MDEMO at the DOS prompt and RETURN, the screen goes blank and a menu appears across the bottom of the screen. This is screen # 1 of an as yet to be named file. It happens to be a blank screen because you have not yet done anything to improve its looks. However, there are things you can do. You can "Edit" it by selecting "Edit." You can create a box and "Place" it anywhere on the screen. When you're finished doing either of the above, press <Esc> and you will be asked whether you wish to save the screen, and if so, name the file that will become the presentation you are working on. From that point on you can perform a number of other operations upon that screen: like choosing the "More" menu selection to see the other half of the menu and then duplicating the screen or inserting a blank screen, to name two. Or, upon startup, you could select "Files" and "Fetch" a file that you previously worked on. Or, if you are already working on a file, choose "Files" again to suspend operations in the work-in-process in order to look at another file with the possible goal of inserting one or more screens from it into the work-in-process. Or you could look at previously "captured" screens and insert them where desired. Or you can look at an ASCII text file and import 25 line chunks. Before we go on; we assume that you have digested the "Help" file, "MDEMO.HLP". You saw them when you ran "DEMO.BAT." Or if you have dabbled with creating a presentation or two and have pressed F1, you got to the same file. It's important that you spend some time viewing this presentation before going any further in this manual. There's little sense duplicating that same information here when viewing it as a presentation is so much more satisfying. That done, you need to know that the "Help" file is not just for viewing. Disect it, take it apart. That's right -- go into MakeDemo and edit them and see some of the behind-the-scenes stuff. MDEMO is just the editor, if you will; MSHOW, the presentor. We can talk a lot about interactive menus, but a picture is worth a thousand words, so to speak. Go on: fetch a presentation, move through the screens with a mouse or arrow keys and then "Save" it. Now you can save some of the screens to a new file and then work on them separately. Or you can save a screen to disk and "Fetch" it later into another file or the same file but in a different place in the sequence of screens. When working on a file, MDEMO handles screens just like a word processor handles pages, except shuffling screens is a little easier than shuffling pages. Changing the order of screens can only be done with adjacent screens; and then you can only swap the shown screen with the next screen or the previous screen. You can walk a screen to a new location, but if the number of screens to bypass is great, you might better "Save" the screen and then "Fetch" it at the desired location. Don't forget to go back and delete the screen at its original loaction. For ease in handling, anticipate the presentation you wish to create and try to break it down into a number of modules: something along the lines of how you might define a number of menu selections. Work on these individually and when you are finished with the pieces, combine them for the final result. MDEMO Features: MDEMO has a number of features that make it easy for you to create stunning screens with a minimum of effort. Not only can you edit anywhere on the screen, "Window" gives you the capability to outline portion of the screen and, in effect, "capture" that portion for editing. Turn on the "word-wrap" feature by pressing <Insert>. You can "Recolor" that portion with the F3 and F4 function keys, you can make a "Copy" of it, or "Erase" it or "Move" it and "Place" it somewhere else on that screen or another. And you can resize the window by moving the lower right corner using the <Ctrl> up arrow, down arrow, PgUp, and PgDn keys. Remember to always "Place" a box you have created or a portion of a screen that you have copied or moved before pressing <Escape> to return to the main menu. In the event that you press <Esc> without first "placing," in answer to the question, "Save Screen?", answer "No." and try again. When you want to "place" a segment on another screen, as long as the segment has not been "erased" in memory, it can still be "placed." Using a Mouse: MDEMO is mouse aware; ie., if the mouse is NOT positioned in the upper left corner of the screen. If the mouse is anywhere else, it is active. Pass it over a menu selection and watch that selection become highlighted. Using a mouse really speeds things up. If you don't have one, seriously think of getting one. Whereas some programs let you move a mouse anywhere on the screen with no apparent effect other than seeing the mouse cursor move, MakeDemo immediately shows you "hot" areas of the screen: you'll see the background and foreground color change when the mouse passes over it. If you see what looks like a menu, simply move the mouse to a what looks like a selection and see if its colors change. If it's a selection you wish to make, merely click the left mouse button. Still, for those without a mouse, when a menu appears on the screen, one of the selections is already highlighted. You can use the arrow keys to maneuver through the various choices and pressing <Enter> while highlighting a particular one, selects that one. Backing out takes a few more words to explain. Whether using a mouse or not, pressing <Esc> any time causes one to step back up through the menu tree and eventually out to DOS with possibly some questions to answer (MDEMO only) before allowing further retreat. But the mouse works a little differently whether you are using MakeDemo or viewing a presentation outside of MakeDemo. If within MakeDemo, moving the mouse off a possible selection and clicking the left button does the same thing as pressing the <Escape> key. If viewing a presentation, such action is ignored. Instead, you must move the mouse right to display the "mouse bar" on the right edge and move it to the "Quit" row and then click the left button. You might ask, "Should I use the mouse in preference to the arrow keys?" Our experience indicates that using both can really speed things up. The trick we use here at WindhamWoods Publishing in making presentations is to primarily use the mouse with the right hand to block segments of the screen for moving and copying etc., and with the left hand, be ready to press the appropriate first letter of the command or menu selection for what we want to do with it. Even if you have chosen to hide the menu bars on the bottom lines of the screen, the selections still work. It saves steps later after you know the more commonly used keys. You might want to temporarily disable the mouse when you're moving or copying a segment around on the screen. Remember to move the mouse to the screen's upper left corner. When using the mouse to move "pick & place" segments around on the screen, note that the segment tries to adjust itself so that its lower right corner aligns with the mouse. This is not always possible, especially when the segment is wide, and then the mouse appears to have no effect. Just be aware. Clicking the left button once anchors the box temporarily and brings up a second menu on the next to bottom line of the screen. It is not necessary to see this menu to use it. Once you know what selections are available you can select one directly by pressing the appropriate capitalized letter for that selection. Large Fonts: After selecting "Edit" you can then select "Fonts" by pressing the function key, F10. You will be presented with a window displaying a word in one of the many fonts that are available. Press <Return> to select the displayed font; any other key will display the same word in another font. Continually pressing a key other than <Return> will cycle through all the available fonts. Using any of the large fonts is somewhat crude. For simple tasks like making titles, etc., they work fine. However, don't expect to be able to word wrap. In using large fonts, it's best to get what you want on each line and then use "Pick & Place" to move a screen segment into final position, etc. When you are finished using a large font, one press of <Escape> first gets you back to normnal font; a second press gets you out of the "Edit" mode. PLEASE NOTE: The fonts are contained in FONTS.WWP, an ASCII file that you can add to or modify to your own wishes. The system is pretty easy to figure out. Just be consistent. Appearance Modes: There are three aspects to presenting a screen. First is the method such as simulated blinds or sprinkling. There are over 20 choices: some for the entrire screen, some for overlays where only a portion of the screen is updated. A second aspect is "sound." Some of the methods have a built in sound effect unique to that method. In general, it's best to forgo the sound effects except where you desire to emphasize a particularly strong point. They wear pretty thin after hearing them a few times. And lastly, there is the duration with 5 choices available. To define the appearance options, they can be accessed by selecting "More" at the main menu and then selecting "Appearance." Overlays, the Key to Presentation Effects. A screen of 25 rows by 80 columns has room for 2000 characters. However, a screen character also has color information. For each character there exists a color attribute "character" defining the background and foreground color. Therefore, a screen commandeers 4000 bytes, of character space in memory or on disk. There are 8 background (all low intensity) colors and 16 foreground (the same 8 low intensity and 8 new high intensity) colors. MakeDemo makes the assumption that no presentation segment will use a low intensity foreground color on a black background. It really looks pretty drab. But that is not strickly true. As long as a segment box has a top and left edge of a high intensity foreground on any background, MakeDemo will be recognize the rectangle so defined as a segment and deal with it accordingly. Just use spaces for the top row and left column. The foreground color is only used for characters. MakeDemo finds the height and width of a segment, as we discussed before, by first finding the upper left corner of a segment, remembering the color attribute of that spot, and "looking" along the top row from left to right for a change in the color attribute or the screen edge, whichever comes first. In like manner, MakeDemo "looks" down the left edge to find the bottom row. Consequently, you can place segments, as defined by their upper and left edges, anywhere on the screen and ShowDemo will be able to find and display them. Stack them or place them side by side. ShowDemo looks for the upper left corner of segments, first from left to right, then top to bottom. Put a "bright" top and left edge on a screen and the screen becomes one segment. Then use one of the display methods that are designed for use with segmments, such as scrolling and sliding. Viewing a Work-in-Process: MDEMO gives you the ability to shell out to DOS. Once at DOS again you run any program including MSHOW to view your work-in-process. MSHOW.EXE is the file that presents your creation(s). This one file can be used in stand alone fashion to present any number of your creations, as in MSHOW -fMYDEMO or MSHOW -fTHISDEMO or MSHOW -fTHATDEMO for viewing. When finished, remember to type EXIT and <Return> to get back to your MDEMO session. Incidently, MSHOW has the capability for shelling out to DOS should you choose to make it available to your viewers. Or, as discussed in the next section, you can combine YOURDEMO with MSHOW.EXE using WWP_MAKE.EXE to create a single executible file. For uploading and downloading over BBSs this makes the most sense. _________________________________________ VII. Making Single .EXE file presentations Any MakeDemo file can be made into its own .EXE file. But there are a few restrictions. First of all, the number of screens in a file can not exceed 2000. And second, if you want to include your own "Help," it must be part of the same file. I suppose that goes without saying. MSHOW.EXE serves two purposes. It can be used as is to present an MDEMO created file. And it also is the basis for making those smaller single .EXE file presentations. The utility WWP_MAKE.EXE does the work for you, by combining the necessary elements into one file. The command line must include two arguments and, optionally, a third. MYDEMO.EXE, if it already exists, will be replaced with the new. The file names for the two arguments are arbitrary; use any names you like. If WWP_MAKE can not find the file specified by the second argument, it terminates and returns to DOS. C:\MDEMO> WWP_MAKE MYDEMO.EXE PRESENT.MD4 1234567,ABCD ---------- |_ _ _ _ _ |------------ | |Presenting| Branding | | File | Info | |_ _ _ _ _ | | | | | +- - - - - -+ | _ _ _ _| | | | | | | | MSHOW.EXE | | | | | | | | | +- - - - - -+ | | | | +- - - - - - - -+ | | | MYDEMO.EXE | | |_ _ _ | Single | _ _ _ _ _ _ _| | File | +- - - - - - - -+ WWP_MAKE performs a number of functions including a "work around" for a potential problem with machines using DOS versions prior to 3.0. Let me explain. With the advent of 3.0, a single file executible can determine its own file name, while executing, and open itself a second time to make the presentation. To enable your presentations to function on machines using prior versions of DOS, MSHOW looks for the file name hard-coded into the EXE composite file. If you were to "debug" such a file, you would discover its name imbedded in the code. A subtle consequence of this "trick" is that your final creation will only work with DOS versions below 3.0 PROVIDED that you DO NOT CHANGE the name of the executible file after you have created it. It will not work if RENamed. Branding In addition, you have the option of branding your final creation so that, should your viewer not use the correct validation code which you assign, any 'nag' screens in your presentation will be activated. Your creation will not be crippled in any way. Any screen with the name "NAG" will be shown just like any other. You can put anything on it that you like. In fact you can include more than one NAG screen placed strategically in your file, as long as each screen has the name "NAG". Note the third argument in the syntax for using WWP_MAKE.EXE. Here you should replace the number '1234567' with some other number known only to you. That number seeds a quasi random number generator. You can use any seven digit number above 1000000, or one million; followed by a comma, with no spaces; followed by a four digit serial number to replace, ABCD, which you can choose to your liking, greater than 1000. To find the corresponding password for a unique serial number, KEY.EXE has been included. The syntax for using KEY.EXE is KEY 1234567 where 1234567 is the same seed number discussed above. KEY will then ask for the serial number you imbeded in your executible file and will display its corresponding password. For example, if (as we did in DEMO.BAT) you use the seed number, 1234567, and assign a serial number of 1000, then using the utility, KEY.EXE, you would calculate the validation code to be '2236'. ________________________________________________ VIII. MLITE, The MakeDemo Stripped Down Runtime Registered users have requested a MakeDemo runtime that takes up as little disk space as possible while still providing the minimum in fuctionality. MLITE.EXE weighs in at a little over 13 k Bytes. It's sole function is to show a series of screens (i.e. full screens: no overlays.) There is no provision for Help at the touch of the F1 key. There is no support for either a mouse or menus. And branding is not supporeted as well. There are two ways to exit MLITE. The first is the <Esc> key which in addition sets the DOS ERRORLEVEL to a 1. The other is the <Return> or <Enter> key which leaves the DOS ERRORLEVEL set at 0. A presentation can be appended to the end of MLITE, just like with MSHOW, except its length can not exceed 35 k Bytes. That's about 45 screens, give or take. Seven and only seven key strokes are recognized: PgUp or Up Arrow Key Presents previous screen PgDn or Down Arrow Key Presents next screen F5 Toggles between monochrome and color Return or Enter Presents next screen, if it exists, or exits with DOS ERRORLEVEL = 0 Esc Exits presentation with DOS ERRORLEVEL = 1 MLITE is useful for making a front end for other software where a few expository screens would help get the novice users off to a good start. For example, you might want to take a look at START.BAT. We've used it as a way to start MDEMO with a few start-up screens that experienced users can later avoid by calling MDEMO directly from the command line. To those of us in the shareware business, especially ASP members, now we can present a more elaborate shareware message to first time users without mucking up the programs themselves with allocated, but never used again, memory. Disk vendors can now incorporate a small front end on all the disks they distribute. You'll note that START.BAT uses MLITE.EXE with a command line argument: namely the name of the file to present, MESSAGE.1ST. I could have used WWP_MAKE to combine the two into an .EXE file, but I left them separate to minimize the size of the archive. IMPORTANT NOTE: WWP_MAKE expects to append the presentation file to a copy of MSHOW.EXE to produce the final .EXE file. Therefore, if you wish to fool WWP_MAKE into using MLITE.EXE instead, you must REName it to something like MSHOW1.EXE, COPY MLITE.EXE to MSHOW.EXE, run WWP_MAKE, and then REName MSHOW1.EXE to MSHOW.EXE. To automate this process, you might consider writing two batch files and place them in the directory with all the MakeDemo files. Here are the two listings: REM GO_MLITE.BAT COPY MSHOW.EXE MSHOW1.EXE COPY MLITE.EXE MSHOW.EXE and REM GO_MSHOW.BAT COPY MSHOW1.EXE MSHOW.EXE With the MakeDemo directory listed in your "PATH" statement of your AUTOEXEC.BAT file, you can make the switch while working in any other directory. _________________________ IX. MDEMO Quick Reference Function Keys F1 - Help F2 - MakeDemo Logo F3 - Background Color F4 - Foreground Color F5 - Color/ Monochrome F6 - Print (normally off) F7 - (not used) F8 - Grab Color F9 - Menu (normally on) F10 - Fonts ( Edit only) Pick & Place / Box / Recolor Move Box Horizontal Left or Right Arrow Keys Vertical Up or Down Arrow Keys Mouse Mouse controls lower right corner. Box follows. Resize Box Horz. <Ctrl> + Left or Right Arrow Keys Vert. <Ctrl> + <PgUp> or <PgDn> Keys Mouse HOLD DOWN Right Button. Anchors Upper Left Corner. Drag Mouse to Change Size. Release Right Button. Copy Save segment to memory, leaving screen intact. Move Same as "Copy" plus erase blocked screen area. Erase Erase saved screen segment kept in memory. Blank Erase blocked screen segment. Place Replace screen segment with that now visible. ___________________ X. Customer Support WindhamWoods Publishing is a small software company owned and operated by Warren Munroe. At WindhamWoods Publishing we believe that the PRIMARY purpose of business is service, not profit. This concept is fundamental to our approach to product development, production and marketing. WindhamWoods Publishing has been producing top quality computer software at reasonable prices, continuously, since 1989. Please feel free to contact me (Warren Munroe) at any time if you have any questions, comments or suggestions. I can be reached by mail, phone, or Compuserve: Warren Munroe Phone: 603.893.2667 WindhamWoods Publishing Orders & Tech Support 603.893.2667 P. O. Box 314 CompuServe 72260,1700 Windham, NH 03087 U.S.A.